Large file support, often abbreviated to LFS, is the term frequently applied to the ability to create files larger than 2 GiB on 32-bit operating systems.
Traditionally, many operating systems and their underlying file system implementations used 32-bit integers to represent file sizes and positions. Consequently no file could be larger than 232 bytes (4 GiB). The problem was exacerbated by treating the sizes as signed numbers, which further lowered the limit to 231 bytes (2 GiB). Files larger than 2 GiB, too large for 32-bit operating systems to handle, came to be known as large files.
While the 2 GiB limit was quite acceptable at a time when hard disks were smaller, the general increase in storage capacity combined with increased server and desktop file usage, especially for database and multimedia files, led to intense pressure for OS vendors to remove the limitation.
In 1996, multiple vendors responded by forming an industry initiative known as the Large File Summit (thus "LFS" can be considered to stand for either "Large file support" or "Large File Summit"), tasked to define a standardized way to switch to 64-bit numbers to represent file sizes. (Merely ensuring the sizes were treated as unsigned numbers would only up the limit from 2 GiB to 4 GiB, which would have been only a stopgap measure given the explosive growth in data storage.) It is worth noting that 64-bit operating systems such as Tru64 UNIX never had a 32-bit limit to begin with, and hence needed no additional "large file support".
This switch caused deployment issues and required design choices the consequences of which can still be seen:
fseek and ftell operate on file positions of type long int, which is typically 32 bits wide on 32-bit architecture, and cannot be made larger without sacrificing backward compatibility. (This was resolved by introducing new functions fseeko and ftello. On Windows machines, under Visual C++, functions _fseeki64 and _ftelli64 are used.)